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Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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Scope 



This specification provides a definition of a Wide Area Synchronization protocol. The synchronization protocol is based 
upon IrMC level 4. 

The present document covers Wide Area Network Synchronization between current and future mobile communication 
end-user devices, desktop applications and server-based information servers. This is a living document and, as such, it 
will evaluate new technologies (e.g. XML) for inclusion as they become readily available. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Bluetooth: a technology specification for short range radio links between mobile PCs, mobile phones and other portable 
devices, (http: //www.bluetooth.com/) 

GET: the operation of requesting that the server returns an object from to the client as defined in the IrDA IrOBEX 
specification 
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GSM: Global System for Mobile communications 

HTTP: HyperText Transfer Protocol 

IrDA: an industry consortium set up to define a set of short range Ir communications standards, (http: //www.irda.org/) 

Level 1: minimum level support defined in the IrDA IrMC set of specifications 

Level 2: access level support defined in the IrDA IrMC set of specifications 

Level 3: index level support defined in the IrDA IrMC set of specifications 

Level 4: sync level support defined in the IrDA IrMC set of specifications 

MIME: Multipurpose Internet Mail Extension 

PUT: the operation of sending one object from the client to the server as defined in the IrDA IrOBEX specification 

SSL: Secure Socket Layer 

Synchronization: the process of exchanging information between multiple physical or virtual locations for the piupose 
of ensuring that each location's copy of that information reflects the same information content 

vCalendar: a format defined by the IMC for electronic calendaring and scheduling exchange with extensions as defined 
in the IrDA IrMC set of specifications 

vCard: a format defined by the IMC for electronic business card exchange with extensions as defined in the IrDA IrMC 
set of specifications 

WAP: an industry consortium set up to define a set of standards to empower mobile users with wireless devices to 
easily access and interact with information and services, (http: //www. wapforum.com/) 

Wide Area Network: a geographically-large range wireless connection between two or more devices for the purpose of 
transferring information. Large geographical range is typically defined as one kilometer or more in distance 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

Cookie: a method of tracking http-based information 

IETF Internet Engineering Task Force 

IMC Internet Mail Consortium 

Ir Infrared 

IrDA Infrared Data Association 

IrMC Ir Mobile Communications 

IrOBEX h Object EXchange 

OBEX Object Exchange 

PDA Personal Digital Assistant 

PIM Personal Information Manager 

URL: Universal Resource Location 

WAP Wireless Application Protocol 

WML: Wireless Markup Language 

XML: extensible Markup Language 



Background 



4.1 IrlVIC 

The IrMC standard was developed as an extension to the IrDA standard for the purpose of providing an open standard 
for data exchange between mobile devices or between mobile devices and desktops or PDAs. Among other things, 
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IrMC defines four levels of support for information exchange. By definition, each higher level must support all of the 
preceding levels. The four levels are: Level 1 (Minimum Level), Level 2 (Access Level), Level 3 (Index Level), and 
Level 4 (Sync Level). Level 4 does not require Level 3. Level 2 and Level 4 are the most relevant for synchronization. 
IrMC has been adopted by IrDA and Bluetooth initiatives and has wide industry support. 

4.2 Bluetooth 

Bluetooth has adopted the IrMC standard as the basis for their synchronization specification. 

4.3 WAP 

WAP has not specified a synchronization standard. Attempts to form a work group last year were abandoned. 



5 IrMC 

There are two approaches regarding syncing of a mobile device. Either the logic of the synchronization has to be 
controlled by the server or by the mobile device. It has to be decided whether the mobile device should be the client or 
the server in the synchronization process. As the mobile device has a limited amount of memory and limited processing 
capacity, it is desired to perform as much of the processing as possible outside of the mobile device. In this case the 
mobile device becomes the server in the synchronization process, only performing the operations the client tells it to 
perform. This introduces a problem, as the mobile device is an Internet client, and now has to act like a server. How this 
is solved is explained in chapter 6.2. 

To be able to synchronize a mobile device calendar, a set of rules for how to read and write data from and to the mobile 
device has to be defined. It must also be decided how to keep track of changes done in the mobile device. An existing, 
and widely spread, standard for this is IrMC. IrMC provides a model for how to store and access data, such as calendar 
items, contacts and more. IrMC is usually put in the application layer on top of the OBEX layer in an IR stack. The 
purpose of this document is to describe how to apply IrMC and OBEX on the Internet, using 3GPP. This requires 
tunneling of OBEX in 3GPP and reversing the client/server roles. 



Tunnelling of OBEX 



There are two major problems with tunneling OBEX over a wide area network. 

The first problem is that no logical connection is kept between the client and the server. In the same way that HTTP is 
stateless, 3GPP only knows a client at one Request/Response-pair at the time. This means that the state awareness of an 
application has to be implemented by the application. 

The second problem is that the client and the server roles are strictly defined. The client always requests the server and 
never the other way around. To get around this, a protocol has to be defined that emulates the reversion of the roles. 

6.1 Introduction of State 

The problem with achieving state awareness on the Internet is usually solved by creating a session object on the server 
that identifies the client by a cookie. Cookies are not yet a standard of 3GPP and also introduce scalability problems on 
the server side. The option left is to pass a Session Id between the client and the server throughout the session. This 
solution is widely adopted on the Internet today. 

Usually, when state awareness has to be achieved on the Internet, the client is a browser and the Session Id has to be 
passed back and forth in hidden fields of forms. As the synchronization of a calendar application in a mobile phone is 
performed by a program and does not involve a browser and no interactivity with the user, a Session Id only has to be 
passed to the client at initialization of the synchronization process. The client however has to pass the Session Id in 
every request to be identified by the server. 

The Connection Id used in OBEX is a 4-byte number. The Session Id chosen for the synchronization is a 128-bit (16 
bytes) number. Preferably this number should be generated as a GUID (Global Unique Identifier) as these numbers are 
guarantied to be unique. 
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6.2 Client/Server 

In the case of synchronizing a mobile device with a server's data, it is preferable to put the synchronization logic on the 
server side, as the mobile device has limited resources of memory and processing capacity. The synchronization process 
should thus be controlled by the server. The connection however should be initiated by the client. As the Internet 
Request/Response model contradicts this, we have to define a way to get around this. 

The approach is to let the client (the mobile device) consecutively query the server for what operation it wants to 
perform on the client. The client will then perform the action and query the server for a new task. This is repeated until 
the server has no more tasks to perform. 

The client will always call the server with OBEX headers as http POST data. The reason for using POST is that there is 
a size limit for sending data in the URL, using the GET method. Using the POST method also avoids problems with 
special characters, using binary POST (binary POST is not supported in WAP 1.1, however. Another solution is 
provided below). Every client request implies permission for the server to request a client task in its response. 



6.3 Binary Post 



As binary POST is not supported in WAP 1.1, the OBEX headers are base64-encoded and sent as plain text. 

This could result in sending 33% more than the ammount of data neccesary.. The solution is however only temporary, 
awaiting WAP binary POST. 



6.4 



The secure connection 



The authentication process only guaranties that the client and the server can rely on each others identity during the 
connection process. The connection that is established is not secure and could easily be tapped for information. It is 
therefore desired to encrypt all data that is sent between the client and the server. 3GPP currently does not guarantee 
strong enough encryption so we will ensure data is secure and untampered. 

In the case of a synchronization of a mobile calendar over 3GPP, there are actually two different transports that has to 
be considered. First it is the transport from the mobile device to the 3GPP gateway. Then there is the transport from the 
gateway to the web server. The transport from the mobile device to the gateway is sent over GSM, which is fairly well 
encrypted. The transport from the gateway to the web server is not protected in any way though. To solve this problem 
we will use a third party product, e.g. "Wireless Jalda", to establish a protected connection from the gateway to the web 
server. This should be transparent from the mobile device and set up the required SSL connection. 



6.5 



Connect 



The connect sequence sets up the connection from the mobile device to the web server. The session id has to be 
assigned in the first response from the server, as more request/response pairs are needed to complete the authentication 
procedure. The Connect procedure is always invoked by the client. 



The mobile device aierts the web server, sending 
an empty obex push. 



Request 

— > 



<OBEXpush> 



The web server responds with a 16 byte session id 
and the obex headers for connect with authenticate 
chaiiange. The server aiso sends an obex target 
header, indicating calendar synchronization. 



Response 



<obex connect with 
authenticate challenge, WAN 
UUID andtarget> 



Request 

— > 



<obex unauthorized with 
authenticate challenge 
containg user name in realm, 
WAN UUID and who header 



The mobile device responds to the connect request 
by sending an unauthorized response with 
authernticate challenge, forcing the web server to 
authenticate itself. Username is sent as realm. 
Who header with assigned connection id. 



Response 



<r- 



<obex connect with 
authenticate challenge and 
authentication response , 
and connectionid> 



The web server verifies the mobile device and 
authenticates itself. 



<obex success with 
authenticate response, WAN 
UUID and connectionid> 



Request 



— > 



The mobile device verifies the web server and 
sends an obex success. 
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Response 




The web server now starts acting like the a ciientto 
the mobiie device, sending PUT and GET 
operations to the mobiie device. 



6.6 



Disconnect 



Disconnection can either be invoked by the client or be invoked by the server as a last response. The client's session is 
then destroyed in the server. A third case is that the connection is lost for other reasons, e.g. power failure by the client. 
In this case, the session should be timed out automatically. 

6.6.1 Client disconnection 

The client normally should not invoke the disconnection. Should the client however need to disconnect, the following 
sequence should be used: 









Response 

<— 




The web server asks the mobiie device to perform 
some operation. 


Request 


<obex disconnect, WAN 
UUID> 


The mobiie device send an obex disconnect to the 
web server. 


Response 

<— 


- 


The web server destroys the session and responds 
with an empty response. 



6.6.2 Server disconnection 

When the server is done synchronizing its content, it should disconnect the client. The following sequence should be 
used: 





fTT, . 




Response 


<obexdisconnect><obex 
connectionid> 


The web server send an obex disconnect to the 
mobiie device and destroys the session. 




- 


The mobiie device disconnects and sends no more 
requests to the web server. 



6.7 



Put 



The PUT operation sends a named vCalendar object from the server to the mobile device. The PUT operation can only 
be invoked by the web server. 









Response 


<obexput, connectionid> 


The web server sends a put request to the mobiie 
device. 


Request 


<obex put response, WAN 
UUID> 


The mobiie device performs the put operation and 
responds with the resulting obex data. 



6.8 



Get 



The GET operation retrieves a named vCalendar object from the mobile device. The GET operation can only be 
invoked by the web server. 









Response 


<obexget><obextarget> 


The web server sends a get request to the mobiie 
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^ 




device. 


Request 


<WAN UUIDxobexget 
response> 


The mobile device performs the get operation and 
responds with the resulting obex data. 



6.9 



Timeouts 



The operation will wait for N seconds before retry. The timeout will be similar to one used on browsers and 
implementation dependent. 



Use Case 



The user choses "remote sync" and is prompted for the URL, for example www.somesite.com, userid and password. 
The userid will be sent to the server. The userid and the password will be saved in the local storage of the mobile 
device. 



www.somesite.com 
OBEX PUSH 



When the WAP server receives this, it will try to establish an OBEX connection with the mobile device, acting as a 
primary from an OBEX point of view. An OBEX Connect request with a WAN UUID header and an Authentication 
challenge header will be sent. The WAN UUID header will contain a unique 16 byte UUID that will be used to identify 
this session. The server also sends an obex target header, indicating that a syncronization is in progress. 



OBEX Connect With Authenticate 
Challenge header + WAN UUID + target 



When the phone receives the OBEX connect, it will respond with an OBEX Unauthorized response and an Authenticate 
Challenge of it's own. The user id is sent in the realm field in the obex authorize header. From now on, the given UUID 
must be present when a request is sent from the phone to the WAP server. This is the only way that the server can 
recognize the phone. The UUID will be identified with the WAN UUID header, which means that the phone identifies 
itself with the given UUID. The cUent also assigns a connection id that is sent in an obex who header in every request. 



OBEX Unauthorized + WAN UUID header 
+ Authenticate Challenge header + Who 



Receiving this, the WAP server resends the same command as last time but this time also adds the Authenticate 
Response header. The server always sends an obex target header, containg the connection id. 



OBEX Connect + Authenticate Challenge header + 
Authenticate Response header + connectionid 



If the OBEX secondary at this stage verifies the received request-digest with the one generated by itself, the client is 
authenticated and the response will be an OBEX Success with an Authenticate Response header. 



OBEX Success + WAN UUID header + 
Authenticate Response header 
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At this stage the OBEX connection is up and the actual synchronization can start. We are now in the middle of a WAP 
request/response pair and the WAP server response will now contain a OBEX Get command, asking for the mobile's 
Change Log. The steps following are identical to the ones in a local synchronization from an OBEX and IrMC point of 
view, the only real difference is the use of the WAN UUID header when sending from the mobile. Worth mentioning is 
that this form of remoted synchronization is not suited for a slow sync [see reference 2]. The user is supposed to do the 
first synchronization locally, using for example cable or IR. 
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